Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/components/card/mission-card.tsx`:
- Around line 90-96: Update the outdated inline comments near the
isCardClickable logic: change the comment that currently says "비리더: 진행중/평가완료" to
"비리더: 진행중/제출마감/평가완료" and change the comment that currently says "비리더: 진행예정/제출마감"
to "비리더: 진행예정" so they reflect the new branch behavior in isCardClickable (the
non-leader branch now includes ENDED as clickable); locate comments adjacent to
the isCardClickable function and replace the two phrases accordingly.

---

Outside diff comments:
In `@src/api/client/axios.ts`:
- Around line 197-211: The multipart interceptor is retrying requests using
axiosInstance instead of the multipart-specific axiosInstanceForMultipart,
causing retried requests to use JSON headers; modify the retry logic inside the
isRefreshing branch (where failedQueue is pushed and in the then handler that
sets originalRequest.headers.Authorization and calls
axiosInstance(originalRequest)) to call
axiosInstanceForMultipart(originalRequest) when the originalRequest corresponds
to a multipart request (i.e., came from the multipart interceptor), ensuring the
correct Content-Type and instance are used; preserve the same promise handling
for failedQueue resolution/rejection and update any places that enqueue or
resolve with the token to consistently use axiosInstanceForMultipart for
multipart originalRequest objects.

In `@src/api/client/axiosV2.ts`:
- Around line 197-211: The multipart interceptor's retry path is using
axiosInstanceV2 which causes retried multipart requests to lose the multipart
Content-Type; in the isRefreshing branch where failedQueue resolves and in the
retry call (currently invoking axiosInstanceV2(originalRequest)), change those
retries to use axiosInstanceForMultipartV2 so multipart requests are retried
with the proper instance and headers; locate the logic around isRefreshing,
failedQueue, originalRequest and replace axiosInstanceV2 with
axiosInstanceForMultipartV2 in that multipart interceptor.

---

Duplicate comments:
In `@src/api/client/axiosV2.ts`:
- Around line 104-175: This file duplicates the JSON/multipart axios interceptor
logic found in axios.ts; refactor by extracting the shared retry-on-AUTH001
interceptor into a reusable factory (e.g., createAuthRefreshInterceptor) and
apply it to axiosInstanceV2 via axiosInstanceV2.interceptors.response.use by
reusing the same implementation used for axios.ts; specifically move the logic
that checks isAxiosError, error.response, isApiError, AUTH001 handling
(references: axiosInstanceV2.interceptors.response.use, isRefreshing,
failedQueue, processFailedQueue, refreshAccessToken, hasAuthToken, ApiError,
originalRequest) into the factory so both axios.ts and axiosV2.ts can call it
and eliminate the duplicated code paths (ensure the factory returns the success
and failure handlers and preserves token queueing and redirect behavior).
- Around line 62-66: The refreshAccessToken function currently performs a
window.location.href redirect inside its catch block, duplicating redirect logic
already handled by the caller; remove the redirect from refreshAccessToken (keep
returning null or throwing as before) so that only the caller (the interceptor
or code that invokes refreshAccessToken) is responsible for navigating to
'/login'; update refreshAccessToken's catch to log/propagate the error and
return null, and ensure callers check for null and perform the single redirect
there (reference: refreshAccessToken and the axios V2 request/response
interceptor that invokes it).

---

Nitpick comments:
In `@src/api/client/axios.ts`:
- Around line 62-66: The refreshAccessToken function currently performs a
window.location.href = '/login' in its catch block and also returns null,
causing duplicate redirects when callers (the places that call
refreshAccessToken and then check for null at the call sites that currently also
set window.location.href = '/login') handle the failure; remove the redirect
from the catch in refreshAccessToken so it only returns null on failure, leaving
the responsibility of redirecting to the callers that already perform
window.location.href = '/login' after receiving null (update the catch in
refreshAccessToken and verify the calling sites that check its return value
still perform the redirect).
- Around line 104-175: The response-error handling logic in the axiosInstance
interceptor (symbols: axiosInstance, isAxiosError, isApiError, ApiError,
refreshAccessToken, isRefreshing, failedQueue, processFailedQueue, hasAuthToken,
originalRequest) is duplicated for the multipart instance; extract that logic
into a reusable factory function (e.g.,
createResponseErrorInterceptor(retryInstance)) that accepts the retry axios
instance to use for replaying original requests, implements the AUTH001
token-refresh flow including queueing via failedQueue/processFailedQueue and
hasAuthToken checks, and returns the error handler to register with both
axiosInstance and the multipart instance so both reuse the same implementation
and avoid the multipart bug.

In `@src/api/client/axiosV2.ts`:
- Around line 90-102: The hasAuthToken function is duplicated across axios.ts
and axiosV2.ts; extract it into a shared utility (e.g., auth-utils) and import
it from both modules: move the implementation that uses getCookie('accessToken')
and inspects requestConfig?.headers?.Authorization (handling array and string
forms) into a new exported function named hasAuthToken in the shared auth-utils
module, replace the inline definitions in both files with imports of that
function, and keep the same signature (accepting an
InternalAxiosRequestConfig-like param) to avoid breaking call sites.